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Description 

Technical Field 

This invention relates to telecommunications sys- 
tems architecture. 

Background of the Invention 

Traditionally, voice communications and data com- 
munications had been considered to be different kinds 
of communications, and hence have evolved along dif- 
ferent paths. Voice communications systems, and par- 
ticularly telephone systems, have evolved into very fea- 
ture-rich systems that offer users a myriad of features 
such as call forwarding, hunt groups, coverage paths, 
pickup groups, bridging, etc. But voice communications 
systems have also evolved into connection-poor sys- 
tems that generally assume all communications connec- 
tions to be of a single type or, at best, of one of a very 
small set of very similar types. Conversely, data commu- 
nications systems have evolved into feature-poor but 
connection-rich systems that offer users various trans- 
port mechanisms (e.g., circuit-switched, pack- 
et-switched, Asynchronous Transfer Mode, SONET, nar- 
row-band, broad-band, local-area network, wide-area 
network, etc.), media (e.g., facsimile transfers, electronic 
mail, file transfers, compressed and full-bandwidth vid- 
eo, etc.), and protocols (e.g., StarLAN, Ethernet, Inter- 
net, ARPANET, etc.), to name just a few. 

In the recent past, voice communications and data 
communications have been converging, so that now 
both kinds of communications are often provided by the 
same system. For example, ISDN telephony systems 
can carry either voice or data in their B channels, and 
some packet-switching systems handle both packetized 
voice and data. However, depending on whether the sys- 
tem is fundamentally a voice communications system or 
a data communications system, the services provided by 
the system to both the voice communications and the 
data communications have been either feature-poor and 
connect ion -rich, or feature-rich and connection-poor, re- 
spectively. 

With the advent of multi-media communications and 
the integration of voice, data, and video communications 
that multi-media involves, the lack of either a full feature 
set or a full connection set has become unacceptable. 
Consequently, the industry is expending tremendous re- 
. sources in designing new multi-media communications 
systems that are capable of providing both a variety of 
features and connections to multi-media communica- 
tions. But the time and expense involved in the design 
of these new systems is great, and often prohibitive. 
Moreover, these systems are not usually compatible with 
the installed base of voice communications systems and 
data communications systems, and therefore require the 
replacement of the existing communications systems as 
opposed to providing a growth path for expanding the 



existing systems' capabilities to multi-media. 

Hence, what the art requires is a relatively inexpen- 
sive and backward-compatible arrangement for provid- 
ing multi-media services that offers both the feature rich- 
5 ness of voice communications systems and the connec- 
tion richness of data communications systems to all com- 
munications types of the multi-media environment 



Summary of the Invention 
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The invention is directed to solving these and other 
problems and needs of the prior art. Illustratively, accord- 
ing to the invention, a feature-rich but connect ion -pdor 
telecommunications controller, such as a telephone 

15 switching system, is employed as a telecommunications 
(e.g., telephony) feature server for a connection-rich but 
feature-poor telecommunications controller, such as a 
broadband or a multi-media node controller. Each of the 
telecommunications controllers provides connections for 

20 its corresponding endpoints, but the feature-rich tele- 
communications controller provides features for both 
controllers' endpoints. The two controllers cooperate to 
establish connections of a basic type (e.g., voice con- 
nections) between their corresponding endpoints. 

25 Since the feature-rich (e.g., telephone) controlleral- 
ready provides the telecommunications features, there 
is no need to design the feature-poor (e.g., broadband) 
controller to also provide these features. Rather, the fea- 
ture-rich (e.g., telephone) controller can provide the fea- 

30 tures to the feature-poor (e.g., broadband) controller in 
a client-server type of arrangement. Hence, the devel- 
opment time for the connection-rich but feature-poor 
(e.g., broadband) controller is shortened and its devel- 
opment cost is lessened, without a sacrifice in the feature 

35 set that is made available to endpoints served by the con- 
nection-rich (e.g., telephone) controller. Furthermore, 
the provisioning of the rich set of features may be easily 
retrofitted into existing feature-poor (e.g., broadband) 
systems. Correspondingly, connection- rich (e.g., work- 

^0 station) endpoints may be included in, and retrofitted in- 
to, connection-poor (e.g., telephone) systems. Hence, 
the benefits of both types of systems may be obtained 
simultaneously in a relatively short time and at a relative- 
ly low cost. Thus, for example, a broadband or a mul- 

45 ti-media system having the versatility of a telephone sys- 
tem can be easily and inexpensively implemented. Fur- 
thermore, the endpoints of the broadband or multi-media 
system (e.g., workstations) and the endpoints of a tele- 
phone system (e.g., telephone sets) can communicate 

50 with each other, and can do so with the versatility of the 
telephone system. 

According to a first aspect of the invention as 
claimed, a telecommunications system comprises a first 
telecommunications controller providing both basic and 

55 other telecommunications connections between a plural- 
ity of first telecommunications endpoints, and a second 
telecommunications controller connected to the first tel- 
ecommunications controller, providing the basic but not 
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the other telecommunications connections between a 
plurality of second telecommunications endpoints inde- 
pendently of the first telecommunications controller, and 
further providing telecommunications features to both 
(a) the plurality of first telecommunications endpoints 
through the first telecommunications controller and with 
respect to both the basic and the other telecommunica- 
tions connections, and (b) the plurality of second tele- 
communications endpoints independently of the second 
telecommunications controller and with respect to the 
basic telecommunications connections. The first and the 
second telecommunications controllers cooperate to 
T provide the basic telecommunications connections be- 
tween the. first telecommunications endpoints and the 
second telecommunications endpoints. Advantageous- 
ly, the marriage of feature-rich but connect ion -poor sys- 
tems and feature-poor but connection-rich systems is 
obtained thereby, resulting in a combined system that is 
both feature-rich and connection rich. 

According to a second aspect of the invention as 
claimed, a telecommunications system comprises a tel- 
ecommunications controller providing both voice and 
other telecommunications connections between a plural- 
ity of telecommunications endpoints, and a telephone 
switching system connected to the telecommunications 
controller, providing telephone connections but not the 
other telecommunications connections between a plural- 
ity of telephone sets independently of the telecommuni- 
cations controller, and further providing telephony fea- 
tures to both (a) the telephone sets for the telephone con- 
nections independently of the telecommunications con- 
troller, and (b) the telecommunications endpoints for 
both the voice and the other telecommunications con- 
nections through the telecommunications controller. Ad- 
vantageously, since a presumably-already-existing tele- 
phone switching system that is already equipped with the 
telephony features is used as a feature server for the 
connection-rich system, the time and cost of re-develop- 
ing the same features for the connection-rich system is 
avoided. Moreover, the telephone switching system is 
used as a foundation on top of which the connection-rich 
system, such as a multi-media system, is built, without 
the necessity of replacing the telephone system. 

According to a third aspect of the invention as 
claimed, a telecommunications system comprises a first 
and a second stored-program-controlled telephone 
switching system connected to each other and each in- 
cluding, and operating under control of, its own 
stored-program controller, wherein the first telephone 
switching system provides telecommunications connec- 
tions independently of the second telephone switching 
system between a plurality of first telephone sets that are 
connected to the first telephone switching system, and 
further provides telecommunications features to the plu- 
rality of first telephone sets, wherein the second tele- 
phone switching system provides telecommunications 
connections independently of the first telephone switch- 
ing system between a plurality of second telephone sets 



that are connected to the second telephone switching 
system, and further provides telecommunications fea- 
tures to the plurality of second telephone sets, and 
wherein the first and the. second telephone switching 

5 systems cooperate to provide telecommunications con- 
nections between a first telephone set of the plurality of 
first telephone sets and a second telephone set of the 
plurality of second telephone sets, with the stored-pro- 
gram controller of one of the first and the second tele- 

10 phone switching systems acting as a telecommunica- 
tions feature server for the stored-program controller of 
the other of the first and the second telephone switching 
systems to provide the telecommunications features ffer 
both the first telephone set and the second telephone 

15 set. In this man n en feature transparency is easily 
achieved between the two telephone switching systems. 
Feature transparency is the provisioning of service fea- 
tures in such a manner that a user can perceive ho dif- 
ferences occasioned by the need to physically distribute 

20 telecommunication circuits or control. In other words, in- 
ter-switch ing-system calls appear to the user as if they 
were served by a single large switching system. 

These and other advantages and features of the in- 
vention will become more apparent from the following 

25 description of an illustrative embodiment of the invention 
taken together with the drawing. 

Brief Description of the Drawing 

30 FIG. 1 is a block diagram of an illustrative telecom- 
munications system that embodies an example of 
the invention; 



FIG. 2 is a block diagram of relevant control proc- 
35 esses and data structures of the system of FIG. 1 ; 

FIGS. 3-5 are a flow diagram of functions performed 
by the control processes of FIG. 2 to establish a call 
between workstations in the system of FIG. 1; 

40 

FIG. 6 is a flow diagram of functions performed by 
the control processes of FIG. 2 to terminate the call 
of FIGS. 3-5; 

.45 FIGS. 3 and 7-8 are a flow diagram of functions per- 
formed by the control processes of FIG. 2 to estab- 
lish a call originated by a workstation between the 
workstation and a telephone set in the system of 
FIG.1; 

50 

FIG. 9 is a flow diagram of functions performed by 
the control processes of FIG. 2 to terminate the call 
of FIGS. 3 and 7-8; 

55 FIGS. 10-12 are a flow diagram of functions per- 
formed by the control processes of FIG. 2 to estab- 
lish a call originated by a telephone set between the 
telephone set and a workstation in the system of 
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FIG. 1;. . - 

FIG. 13 is a flow diagram of functions performed by 
the control processes of FIG. 2 to terminate the call 
of FIGS. 10-12; • - - 

FIGS. 1 4 and 5 are a flow diagram of functions per- 
formed by the control processes of FIG. 2 to add a 
workstation as a conferee to a call between work- 
stations in the system of FIG. 1 ; 

FIG, 15 Is a flow diagram of functions performed by 
the control processes of FIG. 2 to remove a work- 
station from the conference call of FIGS. 14 and 5; 

FIGS. 16 and 8 are a flow diagram of functions per- 
formed by the control processes of FIG. 2 to add a 
telephone set as a conferee either to a call between 
workstations or to a call between a workstation and 
a telephone set at the workstation's request in the 
system of FIG. 1; 

FIG. 17 is a flow diagram of functions performed by 
the control processes of FIG. 2 to remove a tele- 
phone set from the conference call of FIGS. 16 and 
8; and 

FIG. 18 is a flow diagram of functions performed by 
the control processes of FIG. 2 to add a telephone 
set as a conferee to a call between a workstation 
and a telephone set at the telephone set's request. 

Detailed Description 

FIG. 1 shows an illustrative telecommunications 
system that embodies an example of the invention. The 
system of FIG. 1 is made up of two communications sub- 
systems 1 1 and 1 2 that are interconnected by a commu- 
nications link 10. Only two subsystems are shown for 
simplicity; a plurality of subsystems 11 may be connect- 
ed to (and served by, as discussed below) subsystem 
12. Both subsystems 11 and 12 are substantially con- 
ventional. Subsystem 12 is a feature-rich subsystem, 
such as a telephony subsystem. Subsystem 1 2 illustra- 
tively comprises a telephony switching system, such as 
a private branch exchange (PBX) 13 that provides basic 
(e.g., telephony voice) communications services toa plu- 
rality of telephone sets 18-19. PBX 13 is a stored-pro- 
gram-controlled machine, such as an AT&T Definity® 
PBX. It includes a central processor 14 that executes 
control programs out of its memory 15 and controls a 
switching fabric 16 that provides basic communications 
connections between telephone sets 18-19 as well as 
other endpoints in a conventional manner. 

Subsystem 11 may be substantially any desired 
communications arrangement. For example, it may be 
another telephony subsystem, like subsystem 12. Pref- 
erably however, subsystem 11 is a connections-rich 



subsystem,- such as a data or a multi-mediai communi- 
cations subsystem. Subsystem 11 illustratively compris- 
es a switching node 33, for example a local area network 
(LAN) server, a broadband multi-media switching hub, 
s or an asynchronous transfer mode (ATM) packet switch, 
that provides data or multi-media communications serv- 
ices to a plurality of endpoints such as user workstations 
37-39. Switching node 33 includes a node processor 34 
that executes switching-node control programs out of 
io node memory 35 and controls one or more switching fab- 
rics 36 (e;g., LAN, crosspoint switch, etc.) that provide 
communications connections between workstations 
37-39 as well as other endpoints. For purposes of tnis 
discussion, the principal function performed by node 
*5 processor 34 is that of a name-server or router: it con- 
verts connection requests (received from workstations 
: 37-39) that are expressed in terms of originating and ter- 
minating endpoint names and/or addresses into corre- 
sponding connections (with the aid of PBX 1 3, as will be 
20 made clear below). 

Communications link 10 that interconnects subsys- 
tems 11 and 12 is illustratively an ISDN primary-rate in- 
terface (PRI) link that terminates at PBX 1 3 in a conven- 
tional ISDN port circuit 20. Though only one PRI link 10 
25 \ s shown, a plurality may be used for greater inter-sub- 
system communications capacity. If switching node 33 
uses the ISDN transmission protocol, PRI link 10 also 
terminates in just an ISDN port circuit 40 at switching 
node 33. If switching node 33 uses a different transrnis- 
30 sion protocol, PRI link 10 terminates at node 33 in an 
ISDN port circuit and protocol converter 40. ISDN port 
circuit and protocol converter 40 not only terminates the 
ISDN transmission protocol of PRI link 10 but converts 
between the ISDN transmission protocol and the internal 
35 transmission protocol of node 33, in a conventional man- 
ner. 

PBX 1 3 provides voice connections and its conven- 
tional repertoire of telephony features to telephone sets 
18-19 in a conventional manner, independently of sub- 

40 system 11 . PBX 1 3 also provides the features to work- 
stations 38-39 through switching node 33. Hence, PBX 
1 3 acts as a feature server with respect to switching node 
33, which in turn acts as a client of PBX 1 3, in a cli- 
ent-server type of arrangement. Switching node 33 pro- 

45 vides its conventional repertoire of connections to work- 
stations 37-39 in conjunction with the features provided 
by PBX 13 Specifically, switching node 33 provides the 
connections to workstations 37-39 that result from, and 
effect, the features being provided by PBX 13 to work- 

50 stations 37-39. These may, and generally will, include 
connections other than, or more varied than, those pro- 
vided by PBX 1 3 to telephone sets 1 8^1 9, such as image, 
video, and data connections. Additionally, switching 
node 33 may provide features to workstations 37-3i9 out 

55 of its feature repertoire that are additional to those pro- 
vided by PBX 13 (e.g., video broadcasting and vid- 
eo-on-demand). Connections and features that.are pro- 
vided by switching node 33 to workstations 37-39 and 
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that are beyond those provided by PBX 1 3 are referred 
to herein (from the telephony perspective) as enhanced 
services: Under the direction of PBX 13, PBX 13 and 
switching node 33 cooperate to provide telephony (voice 
communications) connections between telephone sets 
18-19 and workstations 37-39. 

FIG. 2 illustrates the configuration of control proc- 
esses and data structures in the system of FIG. 1 that 
are relevant to this discussion. These control processes 
and data structures exist at the application layer (layer 
7) of the ISO's OSI model of software architecture. Con- 
trol processes and data structures that exist at the lower 
levels and that support the application layer processes 
are not important hereto and are of conventional design; 
hence, they are not shown. The control processes and 
data structures of PBX 13 are stored in memory 1 5, and 
central processor 1 4 executes the control processes out 
of memory 15 and makes use of the data structures in 
memory 15 during execution. Similarly, the control proc- 
esses of switching node 33 are stored in node memory 
35 from where they are executed by node processor 34, 
and control processes of workstations 37-39 are stored 
in workstation memories and are executed therefrom by 
workstation processors. 

As indicated in FIG. 2, PBX 13 includes a conven- 
tional PBX status and translations database (PST) 133 
that stores information about each endpoint (EP) (e.g., 
telephone set 1 8-1 9) served by PBX 1 3. Each endpoint's 
one or more corresponding entries 1 34 in PST 1 33 con- 
tain information that includes the extension number that 
is assigned to the endpoint, the name of the user who is 
associated with the endpoint, the permissions for the 
endpoint, the features that are assigned to and activated 
for the endpoint, and the present status of that endpoint 
(e.g., idle, busy). For each endpoint that is connected 
directly to PBX 13 (i.e., each telephone set 18-19), the 
information also includes the identifying number of the 
PBX port 28-29 (see FIG. 1 ) to which the endpoint is con- 
nected. Because PBX 13 is also required, in the system 
of FIG. 1, to provide services to other endpoints (i.e., 
workstations 37-39), PST 133 must contain information 
entries 134 for these endpoints as well. However, be- 
cause these endpoints are not connected directly to PBX 
13, their entries 134 in PST 133 differ from the entries 
134 for telephone sets 18-19 in that they do not include 
a port identifier. Administration of information for a (gen- 
erally physically non-existent, or virtual) endpoint without 
including an associated port identifier is commonly re- 
ferred to as "administration without hardware", which is 
a conventional capability provided on the AT&T Definity 
PBX: PST 1 33 also includes call records for all present- 
ly-existing calls; 

PBX 1 3 control processes include conventional PBX 
call processing (PCP) 132, which implements features 
on PBX 1 3. With respect to endpoints; such as telephone 
sets 18-19, which are administered in PST 133 with a 
corresponding port number, PCP 132 calls upon a con- 
ventional PBX connection manager (PCM) 1 34 to set up 



or tear down any connections that PCP 132 specifies. 
With respect to endpoints, such as workstations 38-39, 
that are administered yirthout hardware, PCP 132 calls 
upon another pre-specified entity. In this case, the entity 
s is a control process referred to as a PBX feature server 
(PFS) 131, 

PFS 1 31 provides external access to features which 
PBX 13 conventionally provides only to endpoints —tel- 
ephone sets 18-19— that are directly connected to and 
io directly served by PBX 1 3. PCP 1 32 acts as an interface 
between PFS 131 and ISDN port circuit 20, conveying 
signaling information that is received by ISDN port circuit 
20 over the signalinig channel (D channel) of PR I link JO 
to PFS i 31 , and conveying control information generat- 
es ed by PFS 1 31 with respect to workstations 37-39 to 
ISDN port circuit 20 for transmission over the control 
channel of PRI link 10V : PFS 1 31 terminates a PRI tem- 
porary signaling connection (CCITT Q.932 signaling) via 
PCP 132, and performs actions based on the CCITT 
20 Q.932 messaging protocol that is carried by Q: 931 sig- 
naling on the signaling channel. PFS 131 makes the ex- 
istence of subsystem 11 transparent to PBX 13: as far 
as PBX 13 is aware, it merely has a conventional JSDN 
trunk connection (PRI link 10) to the external world, and 
25 it is conventionally administered with a plurality of seem- 
ingly-virtual endpoints (workstations 37-39). 

Control processes of switching node 33 include a 
PBX policy server (PPS) 332 whose function is to provide 
access for workstations 37-39 to PBX 13 features by 
30 means of communicating with PFS 1 31 via PRI link 10, 
an endpoint server (ES) 331 whose function is to provide 
call-request handling between workstations 37-39, and 
a multi-media server (MMS) 333 whose function is to pro- 
vide and manage various types or media of connections 
35 (e.g;, audio, video, image) between workstations 37-39 
and other endpoints as requested. PPS 332 is subsys- 
tem 11's counterpart to PFS 131, ES 331 is the counter- 
part to PCP 1 32, and MMS 333 is the counterpart to PCM 
1 34. The control processes of switching node 33 further 
40 include a PBX proxy agent (PPX) 334 which functions 
as a connection server to PRI link 10 to facilitate calls 
between workstations 37-39 and telephone sets 18-19. 
A separate instance of PPX 334 is created for each tel- 
ephone set 1 8-1 9 that is presently involved in a call be- 
45 tween workstations 37-39 and telephone sets 18-19. To 
the extent that instances of PPX 334 represent tele- 
phone sets 18-1 9 in subsystem 1 1 , the instances of PPX 
334 may be thought of as counterparts to virtual end- 
points on PBX 13. 
50 Control processes of workstations 37-39 are re- 
ferred to herein as endpoint processes (EPs) 370-390, 
a corresponding one per workstation 37-39. Their func- 
tion is to communicate with ES 331 and PPS 332 to ob- 
tain requested services (e.g., communications connec- 
ts tions) for their corresponding workstations 37-39. 

WhilePRI Iink10 is a conventional ISDN link utilizing 
the conventional ISDN transmission protocol, two mes- 
sage sets are carried by this transmission medium: the 
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standard ISDN message set used for messages ex- 
changed between PPX 334 and PCP 1 32, and an FSA 
message set used for messages exchanged between 
PPS 332 and PFS 131 . The FSA is a Q. 932 Remote 
Operation Service Element (RQSE)-based protocol s 
which is carried by Q. 931 USERINFO messages across 
PRI link 10. The FSA message set includes transac- 
tion-origination (MAKE_C ALL), transaction-progress ac- ., 
knowledgment (OPERATION_PROCEED), originating 
party class-of-restrictioiVclass-of-service validation 10 
(ORIG_PARTY), call destination (TERM_PARTY), dis- 
connect (CLEAR_CALL), event notification of various 
events such as call-progress events, e.g. , connect, busy, 
out-of-service, etc. (EVENT_NOTIFI CATION), ongo- 
ing-transaction requests (ADD_PARTY_TO_CALL and is 
DROP_PARTY_;FROM_CALL), and transact bn -com- 
pletion indication (RETURN_RESULT or 
RETURN_ERROR) messages. For handling conference 
calls, the FSA message set also includes ADD_PARTY 
and DROP_PARTY messages. .20 

The following call scenarios illustrate the require- 
ments for the above-mentioned control processes, and 
the manner in which PBX 13 provides features there- 
through for workstations 37-39 of subsystem 11 . 

FIGS. 3-5 illustrate a scenario for call-establishment 25 
between two of the workstations 37-39. A workstation 37 
initiates the call, for example in response to a request 
from a user of workstation 37, by means of its EP_A 370 
sending a request for a call to workstation 38 (EP_B) to 
PPS 332, at step 300. In the request, EP_A 370 identifies 30 
the desired call destination (workstation 38) in some way, ^ 
such as by name, address, or extension number. PPS 
332 receives the request and creates a transaction 
record for the call, at step 302. Transaction records kept 
by PPS 332 and PFS 131 for each inter-subsystem call 35 
tie together the knowledge of the calls between PPS 332 
and PFS 131. The transaction record identifies the orig- 
inating endpoint and address digits, and includes a call 
identifier that PPS 332 assigns to this call. PPS 332 then 
sends the request and the call identifier to PFS 131 40 
across PRI link 10 via a MAKE_C ALL message, at step 
304. PFS 131 receives the MAKE_CALL message and 
creates a transaction record for the call, at step 306. The 
transaction record identifies the originating endpoint and . 
address digits, and includes both the call identifier as- 4$ 
signed by PPS 332 as well as a call identifier that PFS 

331 assigns to this call. PFS 331 then sends this latter 
call identifier to PPS 332 across PRI link 10 via an 
OPE R ATION_PROCE E D message, at step 308. PPS 

332 receives the OPE RATI ON_PROCEED message so 
and enters the call identifier assigned by PFS 331 in its 
own transaction record forthe call, at step 310. PPS 332 
and PFS 331 can now exchange communications about 

the call with each other by identifying the call in the mes- 
sage by the message recipient's own call identifier. ss 

Following step 308, PFS 131 makes a request to 
PCP 1 32, via internal signaling of PBX 1 3, for a call from 
workstation 37 to the address digits, at step 312. PGP 



132 receives the request and performs a conventional 
class-of-restriction/class-of-service (COR/COS) check 
on the request, at step 31 4, by examining entries 1 34 for 
workstation 37 (EP_A) in PST 1 33, as indicated at step 
31 6. This is the first service feature that PBX 1 3 provides 
for subsystem 11. Depending on the results of the 
COR/COS check, as indicated at step 31 8, PCP 1 32 in- 
dicates either invalidity or validity of the call request to 
PFS 131 , at step 320 or 350, respectively. 

If the indication is one of invalidity, at step 320, PFS 

1 31 sends the invalidity indication across PRI link 10 via 
an EVENT_NOTIFICATION message, at step 322. PPS 
332 receives the message and forwards the invalidity in- 
dication to EP_A 370, at step 324. EP_A 370 then noti- 
fies the requestor at workstation 37 of the invalidity of the 
request, at step 326. 

Following step 322, PFS 131 clears its transaction 
record for this call, at step 328*; and sends a 
RETURN^ERROR message across PRI link 10 to PPS 
332, at step 340. PPS 332 receives the message and in 
turn clears its transaction record for this call, at step 342. 
PPS 332 then forwards a return-error notification to 
EP_A 370, at step 344. EP_A 370 receives the notifica- 
tion and clears its call record for this call, at step 346: 
The call thus comes to an unsuccessful end. 

Returning to step 318, if the COR/COS check 
passed, PCP 132 creates a call record for the call, at 
step 350, and sends a validity indication to PFS 131 , at 
step 352: PFS 1 31 receives the validity indication and 
sends it across PRI link 10 via an 
ORIGIN ATI ON_PART Y message, at step 354. PPS 332 
receives the message and forwards the validity indica- 
tion to EP_A 370, at step 356. EP_A 370 receives the 
indication and updates its call status for the call there- 
with, at step 358. 

After indicating request validity at step 352, PCP 132 
determines the destination of the call to be workstation 
38, at step 400 of FIG. 4, by applying the address digits 
to the contents of PST 133. This is the second service 
feature that PBX 1 3 provides for subsystem 1 1 . Assume, 
for example, that entries 1 34 in PST 1 33 for workstation 
38 indicate that workstation 38 subscribes to a call-for- 
warding feature which is activated and which designates 
workstation 39 as the forwarding endpoint. By examining 
entries 134 for workstation 38 (EP_B), at step 402, PCP 

1 32 makes this determination, and in turn examines en- 
tries 134 for workstation 39 (EP_C) to determine if they 
further affect the call destination, also at step 402 : As- 
sume that entries 1 34 for EP_C do not affect the call des- 
tination further. PCP 132 therefore determines at step 
400 from contents of PST 1 33 that the call destination is 
workstation 39 (EP^C), and further determines from 
those contents that EP_C is a virtual endpoint. . It also 
determines from those contents whether or not the end- 
point is busy, at step 404. If EP_C is busy (and its entries 
do not specify a coverage point that can be substituted 
as the destination for the call), PCP 1 32 notifies PFS 1 31 
that the endpoint is busy and therefore cannot be 
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reached, at step 406. PFS 1 31 receives the busy indica- 
tion and sends it across PRI link 10 via an 
E VENT_NOTl FICATION message, at step 408. PPS 
332 receives the message and forwards the busy notifi- 

. cation on to EP_A 370, at step 410. EP_A 370 advises 
the requestor of the destination's busy state, at step 41 2. 
It is now up to the requestor or to EP_A 370 to decide 
what to do next. Typically, EP__A 370 requests that the 
call be cleared, at which point the scenario follows steps 
622 et seq. of FIG. 6, discussed below. 

If PCP 132 finds the endpoint EP_C to not be busy 
at step 404, it notifies PFS 1 31 that the destination is the 

* virtual endpoint EP_C, at step 420. PFS 131 receives 
the destination indication and updates its transaction 
record for the call accordingly, at step 422. PFS 1 31 also 
sends the destination indication across PRI link 10 via a 

1 TERMINATION_PARTY message, at step 424. PPS 332 
receives the message and updates its transaction record 
for the call accordingly, at step 426. PPS 332 then re- 
quests the addition of a phantom endpoint, referred to 
as phantom MMUSR, to the call, by sending an 
ADD_PARTY_TO_CALL message to PFS 331, at step 
428. The phantom endpoint MMUSR is administered in 
PST 1 33 of PBX 1 3 as a virtual endpoint with many call 
appearances. It is used to enable single-party calls to 
existonPBX13,aswillbemadeclearfurtherbelow. PFS 
131 receives the message and requests PCP 132 toadd 
phantom MMUSR to the call, at step/430. PCP 132 re- 
sponds by adding a call appearance of phantom 
MMUSR to the call, at step 432, modifying entries 134 
for phantom MMUSR in PST 133 in the process, as in- 
dicated at step 433. PFS 131 then updates its transaction 
record accordingly, at step 442, arid indicates to PPS 332 
that phantom MMUSR has been added to the call, by 
sending an AD D_PARTY message across PRI link 10, 
at step 444. PPS 332 receives the message and updates 
its transaction record accordingly, at step 446. PP$ 332 
also forwards the indication,, received at step 426, that 
workstation 39 (EP_C) is the destination of the call, to 
EP_A 370, at step 448. EP__A 370 receives the destina- 
tion indication and requests ES 331 to notify EP_C 390 
and offer it a call from EP_A 370 in a particular medium, 
at step 450. ES 331 notifies EP_C 390, at step 452. The 
notice indicates the medium or media in which the call is 
to be conducted. 

EP_C 390 can either accept or reject the call. If it 
rejects the call, it so notifies ES 331 , at step 460. ES 331 
in turn notifies EP_A 370, at step 462. It is now up to 
EP_A 370 to decide how to proceed. Normally, however, 
EP_A 370 responds by requesting PPS 332 to drop the 
call destination (EP_C) from the call, at step 464. PPS 
. 332 receives the request and updates its transaction 
record accordingly, at step 466. PPS 332 also sends a 
DROP_PARTY_FROM_CALL message across PRI link 
c 10 requesting that EP_C be dropped from the call, at step 

468. PFS 131 receives the message and updates its 
transaction record accordingly, at step 470. PFS 131 
also requests PCP 132 to drop EP_C from the call, at 



step 472. PCP 1 32 does so, at step 474. It is now up to 
the user of workstation 37 or to EP^A 370 to decide what 
to do next. Choices include selecting another destination 
for.the call (a repeat of the scenario of FIG. 3), or clearing 
s the call (see steps 622 et seq. of FIG: 6). 

If, after being offered the call at step 452, EP_C 390 
decides to accept the call, it so notifies ES 331, at step 
500 of FIG. 5. EP_G 390 also sends a request to MMS 
333 to establish a unidirectional connection from work- 
up station 39 to workstation 37 in whatever medium or me- 
dia were indicated for the call, at step 522. Meanwhile, 
ES 331 receives the indication of call acceptance from 
EP_C 390 arid forwards it to EP_A 370, at step 502: 
EP_A 370 receives the acceptance indication and for- 
15 wards it to PPS 332, at step 504. EP^A 370 also sends 
a request to MMS 333 to establish a unidirectional con- 
nection from workstation 37 to workstation 39 (EP_C 
390) in whatever medium or media its original call re- 
quest encompassed, at step 520. MMS 333 receives the 
20 connection requests from EP_A 370 and EP_C 390 and 
establishes the requested unidirectional connections be- 
tween workstatbns 37 and 39, at step 524: Providing the 
connections in one or more of a plurality of selectable 
media is an enhanced service provided by subsystem 11 
2$ to wofkstations 37-39. Workstations 37 and 39 are now 
participants in a bidirectional, and possibly a multi-me- 
dia, call. 

Returning to step 504, PPS 332 receives the accept- 
ance indication that was forwarded by EP_A 370, and 

30 updates its transaction record accordingly, at step 506. 
PPS 332 also forwards the acceptance indication to PFS 
131 via an EVE NT_NOTI FICATION (CONNECT) mes- 
sage, at step 508. PFS 131 receives the message and 
updates its transaction record accordingly, at step 510. 

35 PFS 131 also indicates the acceptance to PCP 132, at 
step 512. PCP 132 receives the acceptance indication 
and updates the status of workstations 37 and 39 ac- 
cordingly, at step 514, by making appropriate changes 
to the contents of entries 134 in PST 133 for EP_A and 

40 EP_C, as indicated at step 51 6. PBX 1 3 now has a stand- 
ard call record for the call between EP_A, EP_C, and 
phantom MMUSR. This is another service that PBX 13 
provides for subsystem 11 : it keeps track of the present 
status of workstations 37-39, including the status of any 

45 calls that they are participating in. 

FIG. 6 illustrates the scenario for termination of the 
call between workstations 37 and 39 whose establish- 
ment was illustrated in FIGS. 3-5. Assume that worksta- 
tion 39 (EP_C 390) is thefirst to disconnect from the call. 

so EP_C 390 notifies both ES 331 and PPS 332 of the dis- 
connection, at step 600, and requests MMS 333 to dis- 
connect it from EP_A, at step 626. PPS 332 updates its 
transaction record accordingly, at step 602. PPS 332 
also sends the disconnect indicatbn to PFS 131 via an 

ss EVE NT_NOTI Fl CATION (DROPPED) message, at step 
604. PFS 131 also forwards the disconnect notice to 
PCP 132, at step 608. In response* PCP 132 updates 
the status of EP_C, at step 61 0, by modifying its entries 
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134 in PST 133; as indicated at step 612. Even though 
the call is how only a single-party call, because of the 
involvement of .phantom terminal MMUSR in the call, 
PBX 1 3 continues to see the call as (at least) a two-party 
call, and hence it maintains the call, ■ 

Returning to step 600, when ES 331 receives the 
notification of disconnection from EP_C 390, it in turn no- 
tifies EP_A 370, at step 620. EP_A 370 normally re- 
sponds with a clear-call directive, at step 622, which it 
sends to ES 331 and PPS 332; EP_A 370 also requests 
MMS 333 to disconnect it from EP_C, at step 628. MMS 
333 responds to the disconnect requests from EP_C 390 
and EP_A 370 by disconnecting EP_A and EP_G as re- 
quested, at step 630. 

When ES 331 receives the clear-call directive given 
at step 622, it responds by clearing any resources which 
it is managing that were implicated in the call, at step 
624. When PPS 332 receives the clear-call directive, it 
forwards the directive to PFS 131 via a CLEARJ3ALL 
message, at step 636. PFS 1 31 responds by forwarding 
the clear-call directive to PCP 1 32, at step 638. POP 1 32 
views the clear-call directive as EP_A dropping from the 
call, which leaves only the single, phantom, party 
MMUSR on the call. PCP 132 therefore clears the call in 
a conventional manner, at step 640, and updates the sta- 
tus of endpoints that were involved in the call according- 
ly, at step 642. This involves updates to entries 134 of 
EP_A and phantom MMUSR in PST 1 33, as indicated at 
step 644! 

Further in response to the clear-call directive, PFS 
1 31 clears its transaction record for the call, at step 646, 
and notifies PPS 331 via a RETU RN_R E S U LT mes- 
sage, at step 648. PPS 332 receives the message and 
clears its transaction record for the call, at step 650. PPS 
332 also forwards notification thereof to EP_A 370, at 
step 652. EP_A 370 receives the notification and in turn 
clears its call record for the call, at step 654 

FIGS. 3 and 7-8 illustrate a scenario for call estab- 
lishment between one of the workstations 37-39 and one 
of the telephone sets 1 8-1 9, wherein the call is originated 
by the workstation. Assuming that workstation 37 origi- 
nates a call to telephone set 18 (ST_Y), references to 
ST_Y replace references to EP_B in FIG. 3. If, for exam- 
ple, telephone set 18 subscribes to a send-all-calls fea- 
ture which is activated and which designates workstation 
39 (EP_C) as the covering endpoint, the scenario would 
correspond to that shown in FIGS. 3-5 discussed above. 
However, assume instead that telephone set 18 sub- 
scribes to the send-all-calls feature which is activated 
and which designates telephone set 19(ST_Z) as the 
covering endpoint. 

Continuing with this latter scenario, PCP 132 deter- 
mines, at step 700 of FIG. 7, from contents of entries 1 34 
of ST_Y and ST_Z of PST 1 33, as indicated at step 702, 
that the call destination is the physical (as opposed to 
virtual) telephone set 19 (ST_Z). PCP 132 also deter- 
mines from those entries 1 34 whether the destination is 
busy, at step 704. If ST_Z is busy, PCP 1 32 initiates the 



scenario of steps 706-712 which re-creates the scenario 
of steps 406-412, respectively, of FIG. 4. If ST_Z is not 
busy, PCP 132 notifies PFS 131 .of the destination, at 
step 720. In response, PCP 1 32 and PFS 1 31 initiate the 

5 scenario of steps 722-736 which recreates the scenario 
of steps 422-446, respectively, of FIG. 4. In response to 
the destination information that it received at step 726, 
PPS 332 requests PPX 334 to create an instance of it- 
self, called PPX^Z, on behalf of telephone set 1 9 (ST_Z), 

io at step 740. PPX 334 responds by creating a new in- 
stance of itself named PPX^Z, at step 742. PPS 332 then 
provides an identifier, e.g., the name, of PPX_Z, to EP_A 
370 as the destination of the call, at step 744. EP_A 370 
receives the destination identifier and responds by re- 

15 questing that PPX__Z be notified arid requested to partic- 
ipate in the call, at step 746. ES 331 receives the request 
and notifies PPX_Z, at step 748. PPX_Z receives the no- 
tification and makes a request for a bidirectional PRI 
B-channel connection across PRI link 10 by sending a 

20 SETUP message carrying a MAKE_C ALL message 
across PRI link 10 to PCP 132, at step 750. The 
MAKE_CALL message carries the call identifier that had 
been assigned to this call by PPS 332 at step 302 of FIG. 
3. PCP 1 32 receives the SETUP message and forwards 

25 the MAKE_CALL message contained therein/along with 
the call identifier that PCP 1 32 uses for this call, to PFS 
1 31 , at step 754. PFS 1 31 updates its transaction record 
accordingly by entering both of the received call identifi- 
ers in the call's transaction record, at step 752. 

30 in response to the SETUP message that it received 
at step 754, PCP 132 sets up the requested B-channel 
connection across PRI link 10, at step 756, in a conven- 
tional manner. PCP 132 then alerts telephone set 19 
(ST_Z), e.g., by ringing telephone set 19, at step 758. 

35 PCP 132 indicates receipt and progress of the call by 
sending a CALL_PROCEEDING message across PRI 
link 10 to PPX_Z, and sends the alerting status of tele- 
phone set 19 (ST_Z) across PRI link 10 via an ALERT- 
ING message, both at step 800 of FIG. 8. PPXJZ re- 

40 ceives the CALL_PROCEEDING and ALERTiNG mes- 
sages and forwards ian indication of call acceptance and 
alerting to ES 331 , at step 802. ES 331 in turn forwards 
the call-acceptance and alerting indications to EP_A 
370, at step 804/EP_A 370 receives the indications and 

45 updates its call status accordingly, at step 806. 

It is up to workstation 37 to decide how long to wait 
for telephone set 19 to be answered. If telephone set 19 
is not answered within an acceptable period of time, 
workstation 37 usually clears the call. This portion of the 

so scenario is illustrated in steps 912 et seq. of FIG. 9. If, 
however, telephone station 19 (ST_Z) answers the call 
promptly, PCP 1 32 detects the answer in the convention- 
al manner, at step 810, and indicates the answered sta- 
tus of the call to PPX_Z via a CONNECT message that 

55 it sends across PRI link 10, at step 812. In response* 
PPX_Z requests ES 331 to notify EP_:A 370 of the 
call-answered status, at step 814, and also requests 
MMS 333 to establish a unidirectional connection from 
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PPX_Z to EP_A 370 for a voice medium, at step 830, 
and to establish a bidirectional voice connection from 
PPX_ZtothePRl B-channel, at step 834. ES331 notifies 
EP_A 370 of the call-answered status, at step 816. In 
response, EP_A 370 sends a call-acceptance notifica- 
tion to PPS 332, at step 818. PPS 332 receives the ac- 
ceptance notification and updates its transaction record 
accordingly, at step 820. PPS 332 also sends the accept- 
ance notification to PFS 131 via an 
EVENT_NOTI FICATION (CONNECT) message across 
PRI link 1 0, at step 822. PFS 1 31 receives the message 
and updates its transaction record accordingly, at step 
824. 

Having given the call acceptance notification at step 
818, EP_A 370 also requests MMS 333 to establish a 
unidirectional connection to PPX__Z for a voice medium, 
at step 826. In response to the connection requests re- 
ceived from EP_A 370 and PPX_Z, MMS 333 establish- 
es voice connections between EP^A 370 and PPX_Z, at 
step 832, and establishes a voice connection between 
PPX_Z and the PRI B-channel, at step 836. PPX 334 
has associated with itself one or more physical locations 
in a voice-medium switching fabric of switching fabrics 
36, and MMS 333 makes the connections on -behalf of 
PPX_Z to one of these physical locations. Workstation 
37 and telephone set 19 are now participating in a voice 
call. 

FIG. 9 illustrates the scenario for termination of the 
call between workstation 37 and telephone set 19 whose 
establishment was illustrated in FIGS: 3 and 7-8. As- 
sume that telephone set 19 is the first to disconnect from 
the call (disconnection initiated by a workstation is shown 
in FIG. 1 3). PCP 1 32 detects the disconnection in a con- 
ventional manner, at step 900. In response, PCP 132 
gives an indication of the disconnection by sending a 
DISCONNECT message over PRI link 10 to PPX_Z, at 
step 902. PCP 132 also updates the status of endpoints 
involved in the call, at step 904. This includes changing 
the status of telephone 1 9 (ST_Z) in entries 1 34 of PST 
1 33, as indicated at step 906. 

PPX.Z receives the DISCONNECT message from 
PCP 132 and forwards the disconnect indication to ES 
331 , at step 908. PPX_Z also requests MMS 333 to dis- 
connect it from workstation 37 (EP_A), at step 91 8, and 
to disconnect it from the B-channel of PRI link 10, at step 
922. ES 331 forwards the disconnect indication to EP_A 
370, at step 910. In response, EP_A 370 issues a 
clear-call directive to ES 331 and to PPS 332, at step 
912. EP_A 370 also requests MMS 333 to disconnect it 
from PPX_Z, at step 914. In response to the disconnect 
requests received from EP_A 370 and PPX_Z, MMS 333 
disconnects EP_A 370 from PPX_Z 334, at step 920, 
and disconnects PPX_Z 334 from the B-channel of PRI 
link 1 0, at step 924. In response to the clear-call directive, 
ES 331 clears whatever resources were implicated in the 
call, at step 91 6 S and PPS 332 sends the directive via a 
CLEAR_CALL message to PFS 131, at step 930. PFS 
1 31 forwards the clear-call directive to PCP 1 32, at step 



932. In response, PCP 132 clears the call, at step 934, 
and updates the status of endpoints involved in the call, 
at step 936. This includes changing the status of EP_A 
370 and phantom MMUSR in their entries 134 in PST 

5 1 33, as indicated at step 938. 

Further in response to the received clear-call direc- 
tive, PFS 131 clears its transaction record for the call, at 
step 940, and sends a RETURN_RESULT message to 
PPS 332, at step 942. PPS 332 responds by in turn clear- 

io ing its transaction record for the call, at step 944. PPS 
332 then forwards a clear-call notification to EP_A 370, 
at step 948. EP_A 370 responds by clearing its call 
record of the call, at step 950, and the call comes to £n 
end. 

15. - FIGS. 10-12. illustrate a scenario for call establish- 
ment between one of the workstations 37-39 and one of 
the telephone sets 18-19 wherein the call is originated 
by the telephone set. This call scenario could be the re- 
sult of either one of the telephone sets 18-1 9 calling one 

20 of the workstations 37-39, or one of the telephone sets 
18-19 calling another one of the telephone sets 18-19 
but having its call re-directed to one of the workstations 
37-39. • \ 

Assume that telephone set 1 9 calls workstation 37 

25 directly. PCP 1 32 receives a request from telephone set 
1 9 (ST_Z) for a call to workstation 37 (EP_A) in the con- 
ventional manner, at step 1000. In response, PCP 132 
performs the COR/COS check on the request, at step 
1002, by examining entries 134 for telephone set 19 

30 (ST_Z) in PST 133, as indicated at step 1004. If the 
COR/COS check shows the request to be invalid, as de- 
termined at step 1006, PCP 132 indicates invalidity to 
telephone set 1 9, at step 1 008, and the call comes to an 
end in the conventional manner. If it is determined at step 

35 1006 that the request is valid, PCP 132 creates a call 
record for the call, at step 101 0, and then determines the 
destination of the call, at step 1012, from contents of en- 
tries 134 of workstation 37 (EP_A) in PST 133, as indi- 
cated at step 1014. Assuming that these contents do not 

40 change the call destination PCP 1 32 determines that the 
call destination is a virtual endpoint EP_A, and further 
determines from those contents if the destination is busy, 
at step 1016. If workstation 37 is indicated in PST 1 33 to 
be busy, PCP 1 32 gives a conventional busy indfcation 

45 to telephone set 19, at step 1018, and the call then 
comes conventionally to an end. If, however, workstation 
37 is not indicated to be busy, PCP 132 sets up a PRI 
B-channel connection across PRI link 10, at step 1020, 
in a conventional manner. PCP 132 then requests PFS 

50 1 31 to notify the other end of PRI link 1 0 of the existence 
of the call, and provides PFS 131 with a SETUP mes- 
sage and the call identifier that PGP 132 has assigned 
to the call, at step 1022. The SETUP message conven- 
tionally includes identifiers for the call originating and call 

55 terminating endpoints. PFS 1 31 responds to the request 
by creating a transaction record for the call, in which it 
enters the endpoint identifiers and both the received call 
identifier and a call identifier that it assigns to the call, at 
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step 1100 of FIG. 11. PFS 131 alsoenters in the SETUP 
message a MAKE_CALL message which contains a call 
identifier that PFS 131 has assigned to the call, and re- 
turns the SETUP message to PGP 132, at step 1102. 
PCP 132 sends the SETUP message across PRI link 10 
to PPX 334, at step. 1 1 04. PPX 334 receives the SETUP 
message and forwards the MAKE_CALL message con- 
tained therein to PPS 332, at step 1106. PPS 332 re- 
ceives the MAKE_CALL message and creates a trans- 
action record for the call in which it enters both the re- 
ceived call identifier and a call identifier that it assigns to 
the call, at step 1108. PPS 332 then sends this latter call 
identifier to PFS 131 via an OPERATION_PROCEED 
message over PRI link 10, at step 1110. PFS 131 up- 
dates its transaction record with the received call identi- 
fier, at step 1112. 

Further in response to the MAKE__CALL message, 
PPS 332 requests PPX 334 to create an instance of it- 
self, referred to herein as PPX_Z, on behalf of telephone 
set 19 (ST_Z), at step 1114. PPX 334 does so, at step 
1116. PPX_Z then reports call progress to PCP 132 by 
sending a CALL_PROCEEDING message and an 
ALERTING message across PRI link 10, at step 1118. 
PCP 132 receives these messages and updates its call 
status accordingly, at step 1120. 

Having reported call progress to PCP 132, PPX_Z 
also requests ES 331 to notify EP_A 370 and offer it the 
call from ST_Z, at step 1122. ES 331 does so, at step 
11 24. The notice indicates that the call is to be conducted 
in the voice medium. 

EP_A 370 can either accept or reject the call. If it 
rejects the call, it so notifies ES 331, at step 1126. ES 
" 331 in turn notifies PPX_Z, at step 1128. In response, 
/ PPX_Z issues a directive to drop EP_A from the call, at 
step 1130. PPS 332 receives the directive and updates 
its transaction record accordingly, at step 11 32. PPS 332 
also sends the directive across PRI link 10 via a 
DROP_PARTY_FROM__CALL message, at step 1134. 
PFS 1 31 receives this message and updates its trans- 
action record accordingly, at step 1136. PFS 131 also 
requests PCP 132 to drop EP_A from the call, at step 
1138. PCP 132 receives the request and drops EP_A 
from the call s at step 1140, updating its call status ac- 
cordingly, including modifying entries 134 for EP_A in 
PST 133, as indicated at step 1160. 

It is now up to PPX_Z to decide on behalf of tele- 
phone set 19 how to proceed further. The normal course 
of conduct is to terminate the call attempt and clear the 
call, Accordingly, PPX_Z issues a clear-call directive, at 
step 1150. PPS 332 receives the directive and sends it 
across PRI link 10 via a CLE AR_C ALL message, at step 
1 1 52: PFS 1 31 receives this message and forwards the 
clear-call directive to PCP 132, at step 1154. In re- 
sponse, PCP 132 clears the call, at step 1156, and up- 
dates the status of its remaining participant -telephone 
set 1 9- in PST 1 33, at step 1 1 58! Th is involves modifying 
entries 134 for ST_Z in PST 133, as indicated at step 
1160. 



. . Further in response to receiving the clear-call direc- 
tive, PFS 131 clears its transaction record for the call, at 
step 1162, and notifies PPS 332 thereof by sending a 
RETURN_RESULT message across PRI link 10, at step 

5 1164. PPS 332 receives the message and in turn clears 
its transaction record for the call, at step 1166. PPS 332 
also forwards the clear record notification to PPX_Z, at 
step 1168. PPX__Z receives the notice and clears itself, 
thereby ceasing its existence, at step 1170. 

10 Returning to step 1124, assuming that EP^A 370 re- 
sponds to being offered the call from ST_Z by accepting 
the call, at step 1200 of FIG. 12, ES 331 receives an in- 
dication of the acceptance from EP_A 370 and forwards 
it to PPX_Z, at step 1202, PPX_Z in turn forwards the . 

15 acceptance indication to PCP 1 32 by sending a CON- 
NECT message across PRI link 10, at step 1204. PCP 
1 32 receives the message and updates the status of tel- 
ephone set 19 and workstation 39 accordingly, at step 
1 206, by making appropriate changes to the contents of 

20 entries 1 34 for ST_Z and EP_A in PST 1 33, as indicated 
at step 1208. 

In addition to sending the CONNECT message to 
PCP 132 at step 1204, PPX_Z also forwards notification 
of the call acceptance to PPS 332, at step 1210. PPS 

25 332 receives the notification and updates its transaction 
record accordingly, at step 1212. PPS 332 also sends 
an indication of the acceptance to PFS 1 31 via an 
EVENT_NOTIFICATION (CONNECT) message, at step 
1214. PFS 131 receives this message and updates its 

30 transaction record accordingly, at step 1 21 6. In addition, 
PPS 332 requests that phantom MMUSR be added as 
a party to the call, by sending an 
A D D_PA RT Y_TO_C ALL message to PFS 1 31 , at step 
1218. PFS 131 receives this message and request PCP 

35 1 32 to add phantom MMUSR to the call, at step 1 220. 
PCP 1 32 complies, at step 1 222. This includes modifying 
entries 1 34 for phantom MMUSR in PST 1 33, as indicat- 
ed at step 1 224. 

Having requested PCP 132 to add phantom 

40 MMUSR to the call at step 1220, PFS 131 updates its 
transaction record accordingly, at step 1226. PFS 131 
also notifies PPS 332 of the addition of phantom MMUSR 
to the call by sending an ADD_PARTY message across 
PRI link 10, at step 1 228. PPS 332 receives the message 

45 and updates its transaction record accordingly, at step 

1230: 

Returning to step 1200, haying accepted the call, 
EP_A 370 sends a request to MMS 333 to establish a 
voice connection from EP_A 370 to PPX_Z, at step 1 232. 

so Similarly, PPX^Z requests MMS 333 to establish a voice 
connection from PPX_Z to EP_A 370, at step 1234. 
PPX^Z further requests MMS 333 to establish a voice 
connection from PPX_Z to the PRI B-channel that had 
been set up by PCP 132 at step 1020 of FIG. 10, at step 

55 1 238. MMS 333 receives the connection requests from 
EP_A 370 and PPX_Z and establishes voice connec- 
tions between EP_A 370 and PPX_Z, at step 1236, and 
establishes a voice connection between PPX_Z and the 
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■ PRi B-channel, at step 1 240. Workstation 37 and tele- 
phone set 1 9 are now participating in a voice call. 

FIG. 13 illustrates the scenario for termination of the 
call between workstation 37 and telephone set 1 9 whose 
establishment was illustrated in FIGS. 10-12. Assume 
that workstation 37 (EP_A 370) is the first to disconnect 
from the call (disconnection initiated by a telephone set 
is shown in FIG. 9). EP^A 370 notifies ES 331 of the dis- 
connection, at step 1 300. ES 331 forwards the notifica- 
tion to PPX_Z, at step 1 302. PPX_Z in turn forwards the 
notification to PPS 332, at step 1 304. PPS 332 updates 
' its transaction record accordingly/at step 1 306; PPS 332 

■>v also sends the disconnect notification to PFS 1 31 via an 
EVENTJMOTIFICATION (DROPPED) message, at step 
1308. PFS 131 receives this message and updates its 
transaction record accordingly, at step 1310. PFS 131 

*. also forwards the disconnect indication to PGP. 132, at 
step 1 312. In response, PCP 132 updates the status for 

- • thecal!, at step 1314, including modifying entries 134 for 
EP_A in PST 133, as indicated at step 1316. 

■■ Returning to step 1 304, having received the discon- 
nect indication from EP_A 370, PPX_2 also undertakes 
to disconnect from the call and notifies ES 331, at step 
1320; In response, ES 331 clears any resources that 
were implicated in the call, at step 1322. PPX_Z also 
sends an indication of its disconnection Irom the call to 
PCP 132 via a DISCONNECT message, at step 1324. 
PCP 132 receives the message and responds by clear- 
ing the call, at step 1 326. This includes updating entries 
1 34 for ST_Z and phantom MMUSR in PST 1 33, as in- 
dicated at step 1328. PCP 132 then gives a clear-call 
indication to PFS 131, at step 1330. PFS 131 responds 
by forwarding the clear-call indication to PPS 332 via a 
CLEAR_CALL message, at step 1332. PPS 332 re- 
ceives the message and clears its transaction record for 
the call, at step 1 334. It notifies PFS 1 31 thereof by send- 
ing a RETURNJ=IESULT message across PRI link 10, 
at step 1336. PFS 131 receives the message and re- 
sponds by in turn clearing its transaction record for the 
call, at step 1338. 

Returning to steps 1 300 and 1 324, having undertak- 
en to disconnect from the call, EP_A 370 requests MMS 
333 to disconnect it from PPX_Z, at step 1340, and 
PPXJZ requests MMS 333 to disconnect it from EP_A 
370, at step 1342, and from the PRI B channel, at step 
1 346. MMS 333 receives these disconnection requests 
and responds by disconnecting PPX_Z and EP_A 370 
• from each other, at step 1 344, and disconnecting PPX_Z 
and the PRI B-channel from each another, at step 1348. 

FIGS. 14 and 5 present a first scenario for a confer- 
ence call. This scenario assumes the existence of a call 
between workstations -for example, one established ac- 
cording to the scenario of FIGS. 3-5- to which another 
workstation is being added as a conferee. After estab- 
lishment of the inter-workstation call, assume that EP_A 
370 makes a request to add workstation 38 (EP_B) as a 
conferee to the call, at step 1 400. PPS 332 receives the 
request and sends it across PRI link 10 via an 



AD D_PART Y_TO_C ALL message, at step 1402. PFS 
1 31 receives this message and in response requests ad- 
ditionof EP_Btothecall, at step 1404. PCP 132 receives 
this request and determines -^assuming no redirection— 

s that the additional destination for the call is workstation 
38, which is a virtual endpoint from the perspective of 
PBX 13, at step 1406, from contents of entries 134 for 
workstation 38 (EP_B) in PST 1 33, as indicated at step 
1408. It also determines whether or not workstation 38! 

10 is busy, at step 1410. If workstation 38 is busy, the sce- 
nario proceeds at steps 1412-1418 which duplicate the 
steps 406-412 of FIG. 4, discussed above. If EP_B is not 
busy, PCP 132 notifies PFS 131 of the destination,, fet 
step 1420. PFS 131 receives the destination indication 

is and updates its transaction record accordingly, at step 
1422. PFS 131 also sends the destination indication 
across PRI link 1 0 via an ADD^PARTY message, at step 
1424. PPS 332 receives the message and updates its 
transaction record for the call accordingly, at step 1426. 

20 The scenario then proceeds at steps 1 428 et seq. which 
duplicate the steps 448 et seq. of FIGS. A. and 5, dis- 
cussed above, with all references to EP_C 390 and work- 
station 39 in FIGS. 4 and 5 being replaced by references 
to EP_B 380 and workstation 38. 

25 FIG. 15 shows the disconnect scenario for any but 
the last two workstations involved in the conference call 
illustrated in FIG. 14. (The disconnect scenario for the 
last two workstations is shown in FIG. 6). In FIG. 15, 
steps 1500-1520 and 1526-1530 duplicate the steps 

30 600-620 and 626-630, respectively, of FIG. 6. In re- 
sponse to being notified of the disconnection of worksta- 
tion 39 (EP_C) from the call, EP_A 380 does not issue 
a clear-call directive, but merely updates its call record, 
at step 1522. 

35 FIGS. 16 and 8 present a second scenario for a con- 
ference call. This scenario assumes the existence of a 
call between workstations -for example, one estab- 
lished according to the scenario of either FIGS. 3-5 or 
FIGS. 14 and 5- or between a workstation and a first 

to telephone set -for example, one established according 
to the scenario of either FIGS. 3 and 7-8 or FIGS. 10-12- 
to which a telephone set 1 9 is being added as a conferee. 
After establishment of the inter-workstation call, assume 
that EP_A 370 make a request to add telephone set 1 9 

45 (ST_Z) as a conferee to the call, at step 1 600. PPS 332 
receives the request and sends it across PRI link 10 via 
an ADD_PARTY_TO_CALL message, at step 1602, 
PFS 131 receives this message and in response re- 
quests addition of ST_Z to the call, at step 1604. PCP 

50 1 32 receives this request and determines -assuming no 
redirection- that the additional destination for the call is 
telephone set 19, which is a physical endpoint, at step 
1 606, from contents of entries 1 34 for telephone set 1 9 
(ST_Z) in PST 1 33, as indicated at step 1 608. It also de- 

55 termines whether or not ST_Z is busy, at step 1610. if 
ST^Z is busy, the scenario proceeds at steps 1 61 2-1 61 8 
which duplicate the steps 706-712 of FIG. 7, discussed 
above. If ST_Z is not busy, PCP 1 32 notifies PFS 1 31 of 
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the destination, at step 1 620. PFS 1 31 receives the des- 
tination indication and updates its transaction record ac- 
cordingly, at step 1622. PFS 131 also sends the desti- 
nation indication across PRI link 10 via an ADD_PARTY 
message, at step 1624. PPS 332 receives the message 
and updates its transaction record for the call according- 
ly, at step 1626. The scenario then proceeds at steps 
1628 et seq. which duplicate the steps 740 et seq. of 
FIGS. 7 and 8, discussed above. In the case of a second 
telephone set being added as a conferee to a call be- 
tween a workstation and a first telephone set, this will 
result in two PRI B-channel connections being involved 
in the conference call. 

The disconnect scenarios for the conference call il- 
lustrated in FIG. 16 depend on who disconnects when. 
If a workstation disconnects while at least two other 
non-phantom endpoints are engaged in the call, the dis- 
connect scenario for the workstation is the scenario of 
FIG. 1 5. If a telephone set disconnects while at least two 
other non-phantom endpoints are engaged in the call, 
the disconnect scenario for the telephone is that of FIG. 
17. In FIG. 17, steps 1700-1710 and 1714-1724 dupli- 
cate the steps 900-910 and .914-1924, respectively, of 
FIG. 9. In response to being notified of the disconnection 
of telephone set 1 9 (ST_Z) from the call, E P_A 370 does 
not issue a clear-call directive, but merely updates its call 
record, at step 1712. 

For a conference call wherein a workstation 37-39 
is being added to an existing call between telephone sets 
1 8-1 9, the scenario is identical to that for setting up a call 
initiated by a telephone set to a workstation, illustrated 
in FIGS: 10-12. The disconnect scenarios for this con- 
ference call also depend on who disconnects when, as 
in the case of the conference call illustrated in FIG. 16. 

For a conference call wherein a first telephone set 
conferences in a second telephone set to a call involving 
the first telephone set and a workstation* the scenario is 
the conventional conferencing scenario for endpoints 
served by a PBX 13; there is no involvement of subsys- 
tem 1 1 in setting up the conference. The disconnect sce- 
narios are the same as for the conference call illustrated 
in FIG. 16. 

For a conference call wherein a first workstation con- 
ferences in a second workstation to a call involving the 
first workstation and a telephone set, the scenario is the 
one illustrated in FIGS. 14 and 5. The disconnect sce- 
narios are the same as for the conference call illustrated 
in FIG. 16. 

For a conference call wherein a telephone set con- 
ferences in a second workstation to a call involving the 
telephone set and a first workstation, one scenario treats 
the addition of the second workstation as setting up a 
separate call between the telephone set and the second 
workstation, as illustrated in FIGS. 10-12, followed by the 
steps shown in FIG. 18. After the separate calls have 
been established according to the scenario of FIGS. 
10-12, at step 1800, PC P 132 conferences the calls' B 
channels, at step 1802, in a conventional manner by 



means of a conference bridge that constitutes a part of 
the PBX switching fabric 16. PCP 132 also merges the 
separate call's call records into one, at step 1804, and 
forwards to PFS 131 the call identifier of the call whose 

5 call record remains, as a substitute for the call identifiers 
of the call or calls whose call records were merged out, 
at step 1806. PFS 131 updates its transaction records 
accordingly, at step 1 808, resulting in more than one PFS 
transaction record corresponding to the remaining one 

10 (conference) call. 

An alternative scenario eliminates the use of multi- 
ples channels for the conference call by eliminating step 
1020 in FIG. 10 when the second workstation is being 
added, and instead having PGP 132 reuse the B channel 

is that was set up for the initial call between the telephone 
set and the workstation. However, this saving is accom- 
plished at the price of requiring a modification to the con- 
ventional PCP 132 that causes it to recognize and handle 
this type of conference calls differently from conventional 

20 calls. The like alternative, with the like penalty,, may be 
used to avoid the use of two B channels for a conference 
call involving two telephone sets and a workstation, 
shown in FIG. 16. 

The disconnect scenarios are the same, as for the 

25 conference call illustrated in FIG. 16. 

Of course, various changes, modifications, and ex- 
tensions to the illustrative embodiment described above 
will be apparent to those skilled in the art. 

For example, transfer and coverage features are im- 

30. plemented as ADD_PARTY_TO_CALL and 
DROP_,PARTY_FROM_C ALL procedures. Such chang- 
es and modifications can be made without departing 
from the spirit and the scope of the invention and without 
diminishing its attendant advantages. It is therefore ih- 

35 tended that such changes and modifications be covered 
by the following claims. 



Claims 

40 

1. A telecommunications system comprising: 

a first telecommunications controller providing 
both basic and other telecommunications connec- 
tions between a plurality of first telecommunications 

45 endpoints; 

a second telecommunications controller con- 
nected to the first telecommunications controller, 
providing the basic but not the other telecommuni- 
cations connections between a plurality of second 

50 telecommunications endpoints independently of the 
first telecommunications controller, and further pro- 
viding telecommunications features to both (a) the 
plurality of first telecommunications endpoints 
through the first telecommunications controller and 

55 with respect to both the basic and the other telecom- 
munications connections, and (b) the plurality of 
second telecommunications endpoints independ- 
ently of the second telecommunications controller 
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arid with respect to the basic telecommunications 
connections; and 

• the first and the second telecommunications 
controllers cooperating to provide the basic telecom- 
munications connections between the first telecom- 5 
- 1 munications endpoints and the second telecommu- 
nications endpoints. 

^ 2. The telecommunications system of claim 1 wherein: 

the second telecommunications controller io 
operates as a telecommunications feature server lor 
1 the first telecommunications controller. 

' 3. The telecommunications system of claim 1 wherein: 

the first telecommunications controller ts 
responds to features being provided by the second 
telecommunications controller to the first telecom- 
munications endpoints by providing both the basic 
and the other telecommunications connections that 
implement the provided features to the first telecom- 20 
munications endpoints. 

4. The telecommunications system of claim 1 wherein: 

the first telecommunications controller pro- 
vides features other than said telecommunications 25 
features to the first telecommunications endpoints 
independently of the second telecommunications 
controller. 

5. The telecommunications system of claim 1 wherein: 30 

the second telecommunications controller is a 
telephone switching system, the basic telecommu- 
nications connections are voice connections, the 
first telecommunications endpoints are telephones, 
and the telecommunications features are telephony 35 
features. 

6. The telecommunications system of claim 1 further 
comprising: 

first means in the first telecommunications *o 
controller for receiving a request from a first telecom- 
munications endpojnt for a telecommunications con- 
nection; 

second means in the first telecommunications 
controller cooperative with the first means, for send- 45 
ing the received request to the second telecommu- . 
nications controller; 

third means in the second telecommunications 
controller responsive to receipt of the request sent 
by the second means, for processing the request so 
according to the features being provided by the sec- 
ond telecommunications controller to the first tele- 
communications endpoints to determine a telecom- 
munications connection that is to be established in 
response to the request; 55 

fourth means in the second telecommunica- 
tions controller cooperative with the third means, for 
sending to the first telecommunications controller an 
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indication of the telecommunications connection 
that is to be established in response to the request; 

fifth means in the first, telecommunications 
controller responsive to receipt of the indication, for 
establishing the indicated telecommunications con- 
nection. 

7. The telecommunications system of claim 6 wherein: 

the request is for a telecommunications con- 
nection between a pair of endpoints, and 

the third means process the request according 
to the features being provided by the second tele- 
communications controller to the pair of endpoint^. 

8. The telecommunications system of claim 6 wherein: 

; the request specifies at least one of the basic 
and the other telecommunications connections as a 
requested type of telecommunications connection, 
and 

the fifth means establish the requested type of 
the telecommunications connection. 

9. The telecommunications system of claim 6 wherein: 

the fifth means determine at least one of the 
basic and the other telecommunications connec- 
tions to be a requested type of telecommunications 
connection to be established in response to the 
request, and respond to receipt of the indication by 
establishing the indicated telecommu nications con- 
nection as a telecommunications connection of the 
determined type. 

10. The telecommunications system of claim 1 wherein: 

basic telecommunications connections 
include narrow-band connections, and 

the other telecommunications connections 
include broad-band connections. 

11. The telecommunications system of claim 10 
wherein:. 

the narrow-band connections include voice 
connections, and 

the broad-band connections include data con- 
nections, and video or image' connections. 

12. The telecommunications system of claim 11 
wherein: 

the telecommunications features are voice 
telephony features. 

13. The telecommunications system of claim 1 wherein: 

the second telecommunications controller 
includes a database indicating, for each first and 
second telecommunications endpoint, the features 
being provided to said endpoint. 

14. The telecommunications system of claim 13 
wher$in: 



25 



EP 0 696 124 A2 



26 



the database further indicates, for each first 
and second telecommunications endpoint, the 
: present communications status of said endpoint. 

15. A telecommunications system comprising: 

a telecommunications controller providing 
both voice and other telecommunications connec- 
tions between a plurality of telecommunications 
endpoints; 

a telephone switching system connected to 
. the telecommunications controller, providing tele- 
phone connections but not the other telecommuni- 
cations connections between a plurality of telephone 
sets independently of the telecommunications con- 
troller, and further providing telephony features to 
both (a) the telephone sets for the telephone con- 
nections independently of the telecommunications 
controller, and (b) the telecommunications end- 
points for both the voice and the other telecommu- 
nications connections through the telecommunica- 
tions controller. 

16. The telecommunications system of claim 15 
wherein: 

the telecommunications controller and the tel- 
ephone switching system cooperate to provide voice 
connections between the telecommunications end- 
points and the telephone sets. 

17. The telecommunications system of claim 15 
wherein: 

the telephone switching system includes, and 
operates under control of, a stored-program control- 
ler; and 

the stored-program controller is connected to 
the telecommunications controller and operates as 
a telephony feature server for the telecommunica- 
tions controller. 

18. A telecommunications system comprising: 

a first and a second stored-program-controlled 
telephone switching system connected to each 
other and each including, and operating under con- 
trol of, its own stored-program controller; 

the first telephone switching system providing 
telecommunications connections independently of 
the second telephone switching system between a 
plurality of first telephone sets that are connected to 
the first telephone switching system, and further pro- 
viding telecommunications features to the plurality 
of first telephone sets; 

the second telephone switching system pro- 
viding telecommunications connections independ- 
ently of the first telephone switching system 
between a plurality of second telephone sets that are 
connected to the second telephone switching sys- 
tem, and further providing telecommunications fea- 
tures to the plurality of second telephone sets; and 



the first and the second telephone switching 
systems cooperating to provide telecommunications 
connections between a first telephone set of the plu- 
rality of. first telephone sets and a second telephone 

s set of the plurality of second telephone sets, with the 
stored-program controller of one of the first and the 
second telephone switching systems acting as a tel- 
ecommunications feature server for the stored-pro- 
. gram controller of the other of the first and the sec- 

10 ond telephone switching systems to provide the tel- 
ecommunications features for both the first tele- 
phone set and the second telephone set, to effect 
telecommunications feature transparency between 
the first and the second telephone switching sys- 

15 terns for the connection between the first and the 
second telephone sets. 

19. The telecommunications system of claim 17 
wherein: 

20 the first telephone switching system provides 

the telecommunications features for the connec- 
tions between telephone sets of only the plurality of 
first telephone sets independently of the second tel- 
ephone switching system; and 

25 the second telephone switching system pro- 

vides the telecommunications features for the con- 
nections between telephbne sets of only the plurality 
of second telephone sets independently of the first 
telephone switching system. 
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